Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: bhaumik.abhishek@gmail.com (@BhaumikAbhishek)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

@krisrice @AlaaShaker @gebhardtr
Could you please review and merge this pull request.

Security review notes for remediation:

1. High: Unsafe credential persistence in src/oci-kafka-mcp-server/oracle/oci_kafka_mcp_server/tools/connection.py.
   The persist=True path writes a shell-sourceable file containing raw, unescaped user-controlled values, then instructs operators to source it. That creates a shell-injection primitive if any credential contains $(), backticks, quotes, or newlines.
   Remediation: do not emit executable shell syntax for secrets; prefer a non-executable config format, or at minimum shell-escape every value safely and add tests for adversarial inputs.

2. High: oci_kafka_enable_superuser is a one-call privilege-escalation path with no explicit confirmation and no bounded default lifetime.
   Today it is classified as MEDIUM risk and is not in the confirmation-required set, while duration_in_hours=None leaves superuser enabled until someone disables it.
   Remediation: treat this as HIGH risk, require an explicit confirmation step, and require a bounded duration instead of allowing indefinite elevation by default.

3. Medium-High: Untrusted Kafka / OCI data is being fed directly back to the LLM in a write-capable MCP server.
   Topic names, config values, consumer group metadata, work-request errors, and logs are all returned verbatim and the diagnostics tools explicitly expect the LLM to interpret them. In OWASP GenAI terms, this is an indirect prompt-injection / improper-output-handling surface, especially when write tools are enabled in the same session.
   Remediation: treat tool outputs as untrusted, isolate diagnostic/read-only flows from write-capable flows, add stronger human approval for dangerous follow-on actions, and document the trust boundary clearly.

4. Medium: The advertised confirmation control is not actually implementable.
   High-risk tools return confirmation_required, but the tool signatures expose no confirmed flag, nonce, or other stateful approval mechanism, so there is no real way to perform the documented second call “with confirmation”.
   Remediation: add an explicit confirmation parameter or nonce-based two-step workflow and cover it with end-to-end tests.

I ran the package-local test suite (121 passed), but it is heavily mock-based and does not currently catch the issues above.

@krisrice Thanks for the thorough review. All four findings have been addressed in commit 51cb7e7:

1. HIGH — Shell injection in connection.py
   Removed the shell-sourceable export format entirely. The persist path now writes plain .env format (KEY=VALUE) with a comment warning against sourcing. Added _sanitize_env_value() that rejects values containing $, backticks, quotes, newlines, and backslashes — with 9 adversarial input tests covering each vector.

2. HIGH — Superuser privilege escalation
   oci_kafka_enable_superuser is now classified as HIGH risk and added to the CONFIRMATION_REQUIRED set. duration_in_hours is now required (default: 1 hour, max: 24 hours) — indefinite elevation is no longer possible. The tool requires confirmed=True to execute, matching all other HIGH-risk tools.

3. MEDIUM-HIGH — Indirect prompt injection / trust boundaries
   All 36 tool return paths that contain data from Kafka brokers or OCI APIs are now wrapped with _trust_boundary: "untrusted_external_data" and a notice instructing MCP clients and LLM agents not to interpret field values as instructions. Session isolation guidance (read-only default, --allow-writes only in dedicated sessions) is documented in the README Safety Model section.

4. MEDIUM — Confirmation mechanism not implementable
   All 9 HIGH-risk tools now accept a confirmed: bool = False parameter. The two-step flow:

First call (without confirmed=True) → returns {"status": "confirmation_required", ...} with a human-readable warning
Second call (with confirmed=True) → executes the operation
End-to-end tests verify both the confirmation prompt and the duration validation.

Test results: 135 tests passed (14 new), 39.68% coverage.